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[57] ABSTRACT 

The present invention creates a model that maps object 
classes in an object-oriented environment to a data source. 
The model maps the relationship between properties of each 
object class and data of the data source. The present inven- 
tion can be used with a data source such as a relational 
database, user interface, file system, or object-oriented data- 
base. An application's object classes and data source schema 
are designed independent of the other since the model can be 
used to map one to the other. The model is comprised of 
entities and attributes. An entity maps to an object class and 
to at least one table of the DBMS. An entity contains 
attributes either simple or derived. A simple attribute maps 
to a DBMS column. A derived attribute is a combination of 
other attributes and does not directly map to a DBMS 
column. A relationship creates a link between entities of the 
model. A relationship can be used to flatten an attribute or 
flatten a relationship. A flattened attribute is an attribute of 
one entity that is added to another entity. A flattened rela- 
tionship is created by the elimination of intermediate rela- 
tionships between two entities. Relationships can be either 
unidirectional or bi-directional. A unidirectional relationship 
has a single traversal path that has a source entity and a 
destination. A bi-directional relationship has two traversal 
paths. A reflexive relationship can be created using a single 
entity. The model is used to synchronize object properties 
and the data of the data source. 

20 Claims, 18 Drawing Sheets 
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METHOD AND APPARATUS FOR MAPPING 
OBJECTS TO MULTIPLE TABLES OF A 
DATABASE 

This is a continuation of application Ser. No. 08/864,282, 
filed on May 28, 1997, issued Feb. 16, 1999 as VS. Pat, No. 
5,873,093, which is a continuation of application Ser. No. 
08/353,522 filed on Dec. 7, 1994 now abandoned. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates to mapping of data to objects in an 
object-oriented environment. 

2. Background Art 

In a database management system (DBMS), data is stored 
in rows of tables. Each row contains one or more fields or 
columns. Each column contains an item of data. For 
example, an employee table contains rows of employee 
records. Each row, or record, contains information regarding 
an employee. An employee record can contain, for example, 
a last name column that contains a last name of the 
employee. 

Data stored in a column of a table can form the basis of 
a relationship between another table in the database having 
a related column. A relationship can also be formed using 
more than one column per table. Using a relationship 
between columns of two tables, it is possible to join these 
two tables to provide a single table containing instances of 
rows from one table combined with related rows from the 
other table. 

Data from two or more tables can also be joined using 
another capability provided in a DBMS known as a view. A 
view provides the ability to create a virtual table. That is, the 
table created using a view is not considered an actual table. 
Therefore, some DBMS operations, such as update, cannot 
be performed on a view. 

Like a joined table, a view contains rows from one or 
more tables in the database. For example, a view can contain 
the rows from two tables in the database, an employee and 
department table. Such a view may include all or some 
subset of the total number of columns contained in each of 
these tables. For example, the employee table contains 
"employee identification", "department identification", "last 
name", "first name", "street address", "city**, and "zip code" 
columns. The department table contains "department 
identification", "description", "number of employees", and 
"budget" columns. All of the information contained in these 
two tables may not be pertinent or required to allow a user 
to be able to review employee information. For example, a 
department's budget figures are not pertinent to such a 
system. A view can be used to define a virtual table com- 
prised of the columns in the employee table and the employ- 
ee's department description from the department table. The 
"department identification" columns from the two tables can 
be used to join rows from the two tables to form the view. 

Views arc useful to simplify the database schema by 
creating subsets of the database for use with particular 
applications. Further, views can be used to provide security. 
In the above example, the exclusion of the "budget" column 
from the view limits accessibility or knowledge that such a 
column exists. Thus, a user is only made aware of the data 
that the user is authorized to access. One disadvantage of 
views is that they are read-only. Therefore, a view cannot be 
used to update the base tables that actually contain the data 
used to create a view. 
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Another disadvantage of views is that a DBMS restricts 
the operations that are required to create a view. That is, only 
someone with database administrator (DBA) privileges can 
create the virtual tables needed to map objects to the tables 

5 of the DBMS. Therefore, to develop an application includ- 
ing views, it is necessary to have someone with DBA 
privileges available throughout the development phase to 
make changes to existing views and create new views. Once 
an application that includes views is distributed to a user 

10 site, it is necessary to install the application at the user site. 
To install the application at the user site, someone with DBA 
privileges must create the views that are required by the 
application. 

Applications are developed to provide a user with the 

15 ability to facilitate access and manipulation of the data 
contained in a DBMS. A DBMS includes a Data Manipu- 
lation Language (DML) such as Structured Query Language 
(SQL). A DML provides set-oriented relational operations 
for manipulating data in the DBMS. However, a DML 

20 requires a precise syntax that must be used to access and 
manipulate DBMS data. To use a DML, a user must under- 
stand and use the DML/s syntax. Instead of requiring each 
user that wishes to modify a DBMS* data to learn the DML's 
syntax, applications are written that provide an interface 

25 between the user and a DBMS' DML. 

Therefore, applications are developed that provide a user 
interface that allows a user to specify operations to be 
performed on DBMS data in a more user-friendly manner. 
These applications are written in a programming language 

30 such as C, objective C, and SmallTalk, for example. SQL, or 
another database programming language, is embedded in 
these general-purpose programming languages. Once a user 
identifies a data operation, the application uses embedded 
SQL statements to perform the operations on the DBMS data 

35 as directed by the user. 

Some general-purpose programming languages, such as 
objective C and SmallTalk, are referred to as object-oriented 
programming languages. Object-oriented programming lan- 

40 guages define data and the operations that can be performed 
on the data. Such a definition is referred to as an object. To 
use data stored in a DBMS in an application written in an 
object-oriented language, it is necessary to read data stored 
in the DBMS as columns within rows of a record into 

45 objects. Conversely, object data must be read from the object 
and stored in tables in the DBMS. 

A mapping must be performed to determine what DBMS 
data is stored in what object, or conversely, what object data 
is stored in what DBMS tables. There are several disadvan- 

50 tages with the current object-oriented systems* techniques 
for mapping DBMS data to objects. First, data-to-object 
mapping must be represented in the program code of an 
application. That is, an application developer must be aware 
of the DBMS structure or schema and bow the schema is to 

55 be mapped onto the application's objects to develop an 
application. Further, an application must include code to 
define the mapping. Therefore, the DBMS-to-object map- 
ping is not transparent to the user (e.g., the application 
developer). Further, the program code needed to implement 

go this mapping increases the size and complexity of the 
application. The increased coding results in an increase in 
the amount of the effort needed to debug and maintain the 
program code. Further, the DBMS-to-object mapping is not 
dynamic. When a change is made to the DBMS schema, the 

55 application must be re-coded to reflect the schema change. 
Another disadvantage relates to the restrictions that are 
placed on the DBMS schema and/or DBMS-to-object map- 
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ping that can be supported by the current object-oriented their relationship with the second entity. A flattened re la- 
systems. Using current systems, there must be a one-to-one tionship can be created between the first and third entities by 
correspondence between an object and a table in the DBMS. eliminating the first and second relationships. 
Therefore, the schema chosen for the DBMS data is A relationship creates a path that is traversed to resolve 
restricted by the object definitions, or vice versa, 5 the relationship. Neither the object classes nor the data 

Further, because there must be a one-to-one correspon- source need to be aware of the traversal path. The path is 

dence between a table and object, it is not possible to map traversed as needed during model definition and at runtime, 

multiple tables to a single object. Thus, in the example During model definition, the path is traversed to resolve 

described above, it is not possible to map the columns relationships to flatten attributes and relationships. During 

included in the virtual table (i.e., columns from the to runtime, the path is traversed to resolve relationships to 

employee table phis the employee's department description instantiate objects and synchronize objects and the DBMS, 

from the department table) to the properties of a single For example, during runtime, a relationship is used to 

object. identify a join operation that must be performed in the 

DBMS. The relationship and the entity definitions are used 

SUMMARY OF THE INVENTION is to generate an SQL statement that joins the necessary tables 

The present invention creates a model that is used to using the tables* join columns. The result of the join is a 

transparently map object classes in an object-oriented envi- virtual table (i.e., a subset of the tables involved in the join), 

ronment to a data source. The model maps the relationship Data can be extracted from virtual tables to instantiate 

between properties of each object class and data of the data objects and to update the actual table data using the rela- 

source. For example, the model provides a mapping of the 20 tionship definitions defined in the model, 

relationship between properties of each object class and Relationships are unidirectional. A relationship's direc- 

columns of DBMS tables. Other data sources that can be tion is used to resolve the relationship. A unidirectional 

used with the present invention include a user interface, a relationship has a single traversal path that has a source 

file system, and object-oriented database, for example. entity and a destination. Relationship keys from the source 

Prior to model generation, an application's object classes 25 and destination entities (known as source key and the 

and DBMS schema (when a DBMS is used as the data destination key, respectively) are used to traverse the path, 

source) are designed. Each can be designed independent of The source entity and join criteria are used as the criteria for 

the other since the model can be used to map one to the selecting records from the destination entity based on the 

other. Thus, for example, a model can be used to map the source and destination attributes. 

object classes of an existing application to a new DBMS Apair of unidirectional relationships can be used to create 

schema, or vice versa. a bi-directional relationship. A bi-directional relationship 

An object class definition includes properties and behav- has ^° traversal paths. One path traverses from the source 

ior. Properties are the data that is manipulated by the entity to the destination entity. A second path traverses from 

methods (behavior) of the object class. A DBMS schema „ the destination entity to the source entity. A bi-directional 

specifies tables and the columns of the tables, for example. relationship is created using an auxiliary entity. 

The DBMS schema specifies columns from the tables that A relationship is typically created between two different 

can be used for join operations specified using a DBMS data entities. However, a relationship can also be created using a 

manipulation language such as SQL. single entilv - tyi* of relationship is referred to as a 

A model is defined that maps the object classes to the „ rcfl «ive relationship. A reflexive entity uses the same entity 

DBMS schema. The mapping is performed transparendy 45 * c cnUtv and the deshnation entity. One attribute 

such that the object classes and DBMS schema are not of ^ CQtltv » dcfincd 35 thc f 0 ™* kc / wh *> 

necessarily aware of the mapping. For example, there is no another attribute of the source entity is defined as the 

need to implement a class to mirror or accommodate the data destination key. 

source's structure. Similarly, there is no need to design a 45 The model is used at runtime to instantiate instances of an 

data source structure based on object classes. class. Modifications made to the data by a method of 

The model is comprised of entities, attributes and rela- an ob i ect « ^y™*?** 6 * ^ TTt 

tionships. An entity represents the primary structure of the ma PP m S P ro ^ d f b V the mod f 1 model 15 

model An entity maps to an object class and to one or more synchronize the data contained in an object instance and the 

tables of the DBMS. An entity contains attributes and so a source * 

relationships. An attribute can be simple or derived. A BRIEF DESCRIPTION OF THE DRAWINGS 

simple attribute maps to a column of the DBMS. A derived na t mustrates m example of a computer system used 

attribute does not directly map to a column of the DBMS. A to implement me present invention, 

derived attribute can be, for example, a combination of na 2 ovidcs M overvie w of the present invention 

simple attributes operated upon using a mathematical opera- ss ^ a DBMS as a daU 

tion. Simple and derived attributes map to properties of an _JL _ . ■ 

, r r r pjQ 3 provides an overview of a process now for 

object class. eneratin a model 

Relationships can be defined in the model. A relationship .... t * . _ ™ Xjrc u a * a * ~ 

creates a link between at least two entities of the model A \t 7°T ° BMS * P 

relationship can be used to flatten an attribute or flatten a 60 ^ ™th a Personnel application. 

relationship. A flattened attribute is an attribute of one entity 5 ^trates some of the object classes for use with 

that is added to another entity. A flattened relationship is a Personnel application. 

created by the elimination of an intermediate relationship FIG. 6 provides an illustration of the mapping provided by 

between two other entities. For example, a first relationship * model used in the present invention. 

exists between a first and second entity. A second relation- 65 FIG. 7 provides a model generation process flow. 

ship exists between the second entity and a third entity. The FIG. 8 provides an example of a model generated using 

first and third entities are related to each other by virtue of the model generation process flow of FIG. 7. 
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FIG. 9A provides an illustration of displays presented to 
a user to define a flattened attribute. 

FIG. 9B illustrates an update of the model definition of 
FIG. 8 including a flattened attribute entry. 

FIG. 10 illustrates a flatteningAttribute process flow. 5 

FIG. U provides a FlattenRelationship process flow. 

FIG. 12 illustrates a bi-directional relationship using an 
auxiliary entity. 

FIG. 13 illustrates a reflexive relationship. 10 

FIGS. 14A-14C illustrate the FlattenRelationship process 
flow from a user's perspective. 

FIG. 15 provides a fetchloop process flow. 

DETAILED DESCRIPTION OF THE 15 
INVENTION 

A method and apparatus for mapping objects to multiple 
tables of a database is described. In the following 
description, numerous specific details are set forth in order 2Q 
to provide a more thorough description of the present 
invention. It will be apparent, however, to one skilled in the 
art, that the present invention may be practiced without these 
specific details. In other instances, well-known features have 
not been described in detail so as not to obscure the ^ 
invention. 

Hie present invention can be implemented on a general 
purpose computer such as illustrated in FIG. 1. A keyboard 
110 and mouse 111 are coupled to a bi-directional system 
bus 118. The keyboard and mouse are for introducing user 30 
input to the computer system and communicating that user 
input to CPU 113. The computer system of FIG. 1 also 
includes a video memory 114, main memory 115 and mass 
storage 112, all coupled to bi-directional system bus 118 
along with keyboard 110, mouse 111 and CPU 113. The 35 
mass storage 112 may include both fixed and removable 
media, such as magnetic, optical or magnetic optical storage 
systems or any other available mass storage technology. Bus 
118 may contain, for example, 32 address lines for address- 
ing video memory 114 or main memory 115. The system bus ^ 
118 also includes, for example, a 32-bit DATA bus for 
transferring DATA between and among the components, 
such as CPU 113, main memory 115, video memory 114 and 
mass storage 112. Alternatively, multiplex D ATA/address 
lines may be used instead of separate DATA and address 45 
lines. 

The present invention uses a model to map a data source 
to objects in an object-oriented environment The data 
source can be a DBMS, for example. However, a user 
interface, a file system, object-oriented database, or other 50 
data storage system can be used. FIG. 2 provides an over- 
view of the present invention using a DBMS as the data 
source. DBMS schema 202 represents the structure of a 
database. DBMS schema 202 provides information regard- 
ing the tables and columns of the database, for example. The 55 
primary and foreign keys defined for each table are included 
in the DBMS schema 202. 

Object classes 204 include the objects defined to manipu- 
late data for a given application. For example, a personnel 
application, may have objects that manipulate organizational 60 
data for a business. Such an application has an employee 
object, for example, that updates an employee's data. 
Another object updates department information, for 
example. For such an application, DBMS schema 202 has an 
employee table that contains employee information and a 65 
department table that contains data associated with the 
organization's departments, for example. 
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DBMS schema 202 and object classes 204 are used to 
build a model that maps the DBMS schema 202 to the object 
classes 204. The mapping is performed transparently such 
that the object classes and DBMS schema are not aware of 
the other's structure. Model 206 can then be used at runtime 
in conjunction with the data in the database 208 to instantiate 
objects 210 of the application. Objects 210 manipulate the 
data according to tbeir definition. Model 206 is further used 
to map the modifications made by objects 210 into database 
208. 

FIG. 3 illustrates an overview of the process flow for 
generating a model. At block 302, a DBMS is designed. The 
DBMS includes the structure for the data to be used in the 
application. At block 304, the object classes to manipulate 
the data are designed Each object class is defined by the data 
manipulated by the object class and the operations per- 
formed on the data. Using the DBMS and the object classes, 
a model is generated at block 306. 

As described in FIGS. 2 and 3, model 206 is generated 
using the DBMS schema 202 and the object classes 204. 
Model 206 maps the data between the DBMS schema 202 
and the object classes 204. The mapping is performed 
transparently such that the object classes and DBMS schema 
are not necessarily aware of the mapping. For example, there 
is no need to implement a class to accommodate the data 
source's structure. Similarly, there is no need to design a 
data source structure based on object classes. FIG. 6 pro- 
vides an illustration of the mapping provided by model 206. 
Referring to FIG. 6, object classes 622, model 602, and 
DBMS schema 612 correspond to object classes 204, model 
206, and DBMS schema 202, respectively. 

Model 602 is comprised of zero, one or more instances of 
entity 604. (The double arrows directed toward entity 604 
indicates a "to-many" relationship.) Each entity 604 can be 
included in zero, one, or more instances of model 602 (as 
indicated by the double arrows directed from entity 604 to 
model 602). Each entity 604 is defined by zero, one or more 
instances of attribute 606Aor relationship 606B. A relation- 
ship 606B is an affiliation between one or more instances of 
entity 604. 

Entity 604 and attribute 606A represent structures that 
contain data. Using DBMS schema 612, for example, entity 
604 represents a table 614 and attribute 6O6A represents a 
column 61 6 A of table 614. Table 614 is comprised of records 
or rows. Each row of table 614 is an instance of entity 604. 
For example, an employee record of an employee table is an 
instance of an employee entity. Each instance of entity 604 
maps to an instance of object class 624. Object class 624 is 
an instance of Object classes 622. Object class 624 is 
comprised of zero, one, or many instances of property 626. 
A property maps to an attribute 606A or property 626 is 
derived from other instances of property 626, for example. 

Attribute 606Aof entity 604 is either a simple attribute or 
derived, attribute. A simple attributemajg^anjnstance pL 
colum n 616 A having the same name, fo r example^ A derived 
attribute is not mapped to a specific instance of column 
616A. A deri ved attribute can be a c ombinat ion of instanc es 
of column 61 6A, for example. Relationship 606B provides 
the ability tolIeTine an i nstance of entity 604 that maps to 
multiple instances~5T table '"614. An instance of entity 604 
that maps to multiple instances of table 614 maps to a virtual 
table that does not actually exist in DBMS schema 612. The 
virtual table maps to one or more instances of actual tables 
of DBMS schema 612. 

Relationship 606B provides the ability to add attributes 
from other instances of entity 604. The process of adding 
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attributes from other instances of entity 604 is known as s uch as social s ecurity number, or the primary key can be a 

flattening. A flattened attribute is an attribute 606A of a first value that is craleTIlmaHused by the application. Employee 

instance of entity 604 that is included in a second instance table 402 uses the "Employee Id." value as the primary key. 

of entity 604 using relationship 606B. A relationship 606B A table can also contain a column that is the primary key 

that exists between an intermediate instance of entity 604 5 Q f another table. Such a column is referred to as a foreign 

and two other instances of entity 604 each having a rela- k ey Employee table 402 includes two foreign keys, 

uonship with the intermediate instance can be flattened. A "Address Id." and department Id". The "Address Id." 

flattened relationship is created between the two instances foreign key of employee table 402 is the primary key of 

without traversing the relationship that the two entities have address table 422, for example. The "Department Id." for- 

with the intermediate entity. 10 ejgn key of employee table 402 is the primary key of 

Relationship 606B corresponds to a join 616B of DBMS department table 462. 

schema 612. Relationship 606B pairs an ip&tanc^pJLallrifeute, Using the "Department Id " foreign key of employee table 

606A (a source attribute) of the first instance of entity 604 402 and the "Department Id." primary key of department 

witETnlBstance of attribute 606A(a destination attribute) of table 462, a join 470 can be performed between employee 

the second instance of entity 604. Relationship 6O6B is 15 table 402 and department table 462. The resulting join (each 

similar to a join 616B of DBMS schema 612. Join 616B record of the resulting join) can include some or all of the 

pairs an instance column 61 6A (a source column) of a first columns from employee table 40 and some or all of the 

instance of table 614 and an instance of column 616A (a columns from department table 462. Other joins can be 

destination column) of a second instance of table 614 to similarly defined using primary and foreign keys, for 

create records that combine some or all of the instances of 2 o example, between: employee table 402 and projects table 

column 616B from the first and second instances of table 442 (join 478), employee table 402 and address table 422 

614. (join 476), department table 462 and building 482 (join 472), 

There are different types of join 616B. For example, join and between building table 482 and address table 422 (join 

616B can be an inner join, a right outer join, a left outer join, 474). 

or a full outer join. Using an inner join, if a destination 2s Object Classes 

record cannot be found for a given source record, the source In addition to defining a DBMS schema for the data to be 

record is not included in the resulting join. Destination used in an object-oriented application, object classes are 

records that do not match to any source records are not defined to manipulate the data. As previously indicated, an 

included in the resulting join. Using a right outer join, object is comprised of properties (i.e., data) and behavior 

destination records that to do match to a source record are 30 (i.e., method or operations to manipulate the data). An 

included; however, source records that do not have destina- object's properties can be persistent properties that are used 

tion records are not included in resulting join. In a left outer by the application and stored in the DBMS. Other properties 

join, source records that have a matching destination record are considered to be temporary properties because they are 

are included in the resulting join; however, destination used within the application, but they are not stored in the 

records that do not match to a source record are not included 35 DBMS. Temporary properties, for example, may be com- 

in the join. In a full outer join, all source records from both puled from the values of persistent properties or other 

tables are included in the result of the join. temporary properties. Temporary properties can also be used 

Join 616B further uses join operators to perform the join. as flags that indicate a certain state in the application, for 

Such operators include less than ("<")» greater than (">"), example. 

equal to ("-")> less than or equal to ("^"), greater than or 40 FIG. 5 identifies three objects: department object 504, 

equal to ("^")» ano * m * equal to ("o"). The join operator is project object 514, and employee object 524. Each object 

used to specify how the destination column (or attribute) has properties 502, 512, and 522, respectively. Department 

relates to the source column (or attribute). Therefore, joins object 504 contains properties 502 that represent informa- 

and relationships are not limited to cases where the source tion about a department such as "Department Id.", 

and destination column (or attribute) are equal. Instead, it is 45 "Description", "Budget", and "Building Id.", for example, 

possible, for example, to specify a join (or relationship) Similarly, the project object 514 contains the following 

where the destination column (or attribute) is greater than project information, for example: "Project Id.", 

the value of the source column (or attribute). "Description", "Due Date", and "% Complete". Employee 

DBMS Schema object 524 contains properties related to an employee such 

As described in conjunction with FIG. 6, DBMS schema so as "Employee id "Last Name", "First Name", "Middle 

612 is comprised of instances of table 614. Table 614 is Initial", "Salary", "Department Id", and "Address", for 

comprised of instances of column 616A Instances of col- example. 

umn 616A are used with a join 616B to join instances of Each object's definition in FIG. 5 contains a definition of 

table 614. FIG. 4 illustrates a portion of a DBMS schema the object's, behavior. An object's behavior is implemented 

adapted for use with a personnel application. The DBMS ss as one or more methods that operate on one or more 

schema of FIG. 4 includes five tables: employee table 402, properties of the object. For example, employee object 524 

address table 422, projects table 442, department table 462, can contain a method to set an employee's salary 

and building table 482. ("setSalary"), define an employee's address ("Address"), or 

Employee table 402 contains columns "Address Id", specify an employee's name ("setName"). The method to set 

"Employee Id.", "Last Name", "First Name", "Middle 60 an employee's salary operates on the "salary" property of 

Initial", "Department Id.", and "Salary". A table in a DBMS the employee object, for example. The "Address" method 

typically uses one or more columns to uniquely identify a modifies an employee's address. The "setName" method 

record in the table. A column that umquejy _identifies a modifies the "Last Name", "First Name", and "Middle 

record in actable js referred [ to_a^pjimarxtey?v^ere two Initial" values for an employee. 

or more columns are used to uniquely identify a record, the 65 Other examples of object classes include department 

columns are referred to as a compound primary key. The object 504 and project object 514. Department object 504 

value of the primary key can represent a "real-world" value includes properties 502 (i.e., "Department Id.", 
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"Description", "Budget", "Building Id."), for example. At block 706, the attributes for each entity in the model 

Department object 504 contains, for example, a method to are defined. An attribute is an identifiable characteristic of an 

set a department's budget. Project object 514 has properties entity. An attribute is a simple attribute, derived attribute, or 

512 including "Project Id.", "Description'*, "Due Date", and a relationship. A simple attribute corresponds directly to a 

"% Complete", for example. Project object 514 includes, for 5 single column of a DBMS table. A derived attribute does not 

example, a method ("update%Complete") to update the "% map directly to a single column of a DBMS table. A derived 

Complete" property. attribute is derived based on the value of one or more other 

Model attributes. For example, a derived attribute, "Total Income" 

Once object classes and a DBMS schema are denned, a is the result of the addition of an employee's "Salary" and 

model can be defined to establish a mapping between the 1Q "Bonus" attribute values. 

classes and the DBMS schema. The model maps the rcla- At block 708, relationships are created between at least 

tionship between persistent properties of each object class two entities in the model entities are generated. A relation- 

and the columns, or fields, in DBMS tables. The mapping is ship creates a link between at least two entities and the 

performed transparently such that the object classes and objects associated with the entities. A relationship creates a 

DBMS schema are unaware of the structure of the other. For mapping between an object and one or more tables of the 

example, there is no need to implement a class to mirror the 15 DBMS. 

data source's structure, or to design a data source structure At block 710, one or more relationships that are created 

based on object classes. J at block 708 can be used to define a flatte^ejijati^ 

la the preferred embodiment, an interactive approach is flaltened-reUtionshipjEbk attribute uses 

used to generate a model. Using an interactive approach, a a relauonsMj^armeA^ allow one entityjo 

series of displays can be provided to a user to display a 20 contam"the" attributes of another entity. AJaft^^TOIaticjx- 

current model and allow the model to be updated. A current smp^re^tes^ajdS 

model can initially be empty or contain an existing model. omerwisj^Jnjjl^ For 

An existing model may, for example, be created using the example, a first entity and a second entity are directly related 

DBMS schema. An existing model can be a model that has via a relationship and the second entity and a third entity are 

previously been customized for use with the application, for 25 related via a direct relationship. The relationship between 

example. The interactive model generation approach is used the first entity and the second entity and the relationship 

to customize, or update, the current model to accommodate between the second entity and the third entity are flattened 

an application's design. to create a relationship between the first and third entities. 1 

Other model generation approaches can be used in con- Flattened Attribute ^ 

junction with the present invention to generate a model. For 30 The present invention provides the ability to define a 

example, a language can be developed such that one or more flattened attribute. A flattened attribute is a special kind of 

statements using this language can be written to define the derived attribute that provides the ability to add an attribute 

model. Statements written using this language express a from one entity to another entity by traversing a relationship, 

model definition. These statements are submitted to a model Using a flattened attribute, an entity and an object associated 

generation engine, for example. The model generation 35 with the entity are mapped to columns contained in more 

engine parses the statements and uses the statements to than one table of the DBMS. 

update the model Flattening an attribute creates a join between two or more 

Using any approach to define a model, a current model is tables in a DBMS. In a DBMS, a join is an operation that 

used to specify a mapping between the DBMS and object provides access to data from more than one table at the same 

classes. FIG. 7 illustrates a process for creating a model that 40 time. The join is performed using a related column from 

defines the relationship between a DBMS and object classes each table. These columns are referred to as join columns, 

and between columns of tables of a DBMS with properties For example, referring to FIG. 4, the employee table 402 can 

of object classes. FIG. 8 illustrates a model generated using be joined with the department table 462 using the "Depart- 

the model generation process of FIG. 7. ment Id" columns from the two tables. By joining a row 

At block 702, a model entity is created for each database 45 from each table when the values in the join columns are 

table in the DBMS schema of the application. Referring to equal, a combined row is created that includes the informa- 

FIG. 8, model entities 802, 822, 842, 862, and 882 are tion about an employee from the employee table 402 and the 

created and correspond to DBMS tables 402 (employee information about the department to which the employee is 

table), 422 (address table), 442 (project table), 462 assigned from department table 462. 

(department table), and 482 (building table), for example. At 50 In the model, a flattened attribute provides the ability to 

block 704, an object class is associated with a model entity. join attributes from multiple model entities. Thus, for 

For example, referring to FIG. 5, the employee model entity example, the employee entity 802 can contain the descrip- 

802 is associated with the employee object class 524, project tion of the department (from the department model entity 

object class 514 is associated with project model entity 842, 862) to which an employee is assigned. Further, the employ- 

and department object class 504 is associated with depart- 55 ee's address attributes (from the address model entity 822) 

ment model entity 862. can be included in the employee model entity 822, for 

By associating an object class with an entity, the model- example. 

DBMS mapping is applied to the associated object class. Referring to FIG. 8, model entity 802 is the model entity 

This enables an object class to remain synchronized with the associated with the employee table 402 of FIG. 4. Referring 

DBMS during runtime. Thus, an object's properties can be 60 to FIG. 4, employee table 402 contains a join column, 

mapped to columns in DBMS tables via the model (i.e., the "Department Id." that corresponds to a join column, 

entity to DBMS table mapping). When an object modifies its "Department Id." of the Department table 462. Referring to 

properties, the modifications can be propagated to tables in FIG. 8, model entity 802 contains an attribute, "Department 

the DBMS. Conversely, when modifications are made to Id., that corresponds to the "Department Id." attribute in 

columns in the DBMS, the modifications can be propagated 65 department entity 862. A "toDepartment" relationship 870 

to properties of an object. Therefore, a class of objects can can be created between the employee table 402 and depart- 

remain synchronized with the DBMS. ment table 462 using these two attributes. 
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To flatten an attribute, a relationship is first created 
between the entities. An attribute from each model entity is 
identified as a relationship key. Two relationship keys, a 
source key and a destination key, are defined to establish a 
traversal path between the entities having the flattened 
attribute relationship. The source key is defined for the 
source model entity and a destination key is defined for the 
destination model entity. The source key establishes the 
comparison criteria used to resolve the relationship. The 
destination key provides input for the comparison to the 
source key. A traversal path is used to allow the inclusion of 
one entity's attributes in another entity to define the model. 
Further, the traversal path is used to resolve a relationship 
between objects at runtime. Runtime resolution of object 
relationships is discussed below. 

FIG. 10 illustrates a flatteningAttribute process flow using 
the interactive approach of the preferred embodiment. To 
flatten an attribute during model definition, a traversal path 
is defined between the entities having the flattened attribute 
relationship. The traversal path is defined by identifying 
source and destination model entities and identifying the 
relationship keys of both these entities. Once the traversal 
path is defined, the traversal path is used to resolve the 
relationship between the entities (and the associated object 
classes). Thus, at block 1002, a source entity is selected from 
the model. An "add relationship" operation is specified at 
block 1004. At block 1006, a destination entity is selected 
from the model. A source key is selected from the attributes 
of the source entity at block 1008. At block 1010, a desti- 
nation key is selected from the attributes of the destination 
entity. At this point, a traversal path between the source and 
destination entities is defined. 

At block 1012, the properties of the relationship can be 
defined. Properties of the relationship include, for example, 
the type of join, the operator to be used to perform the join, 
and the relationship's cardinality. The join can be, for 
example, an inner join, full outer join, left outer join, or right 
outer join. The join operator further refines the criteria used 
when the join is performed. For example, if an equals ("=") 
operator is specified, an equijoin is performed. Using an 
equijoin, records from the destination entity are joined with 
the source record only when the source and destination keys 
have equal values. The cardinality specifies whether the 
relationship is a "to-one" or "to-many" relationship between 
the source and destination entities. 

Once a relationship, or traversal path, is defined between 
two entities, the attributes of the destination entity can be 
added to the source entity. Referring to FIG. 8, the "Descrip- 
tion" attribute of the department entity 862 is to be included 
in the employee entity 802. By doing so, an employee's 
department description is supplied to the employee object 
524 that is associated with the employee entity 802 when the 
employee object 524 is instantiated at runtime. A relation- 
ship must be established between the employee entity 802 
and the department entity 862. A traversal path is chosen 
between the two entities. The employee entity 802 is chosen 
as the source entity since the flattened attribute is to be added 
to this entity. The entity containing the attribute to be 
flattened is chosen as the destination. 

The "Department Id." attributes of the two entities are 
selected as the relationship keys. Each department has a 
"Department Id." that uniquely identifies a department 
instance. Each employee has a "Department Id." that points 
to a unique instance of department. Therefore, the relation- 
ship between employee model entity 802 and the department 
model entity 862 can be resolved using the "Department Id." 
attribute for both entities. 
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Using the "Department Id." attribute as the relationship 
key, a "toDepartmenr" relationship 870 is defined between 
the employee entity 802 and department entity 862. The 
"toDepartmenr" relationship 870 is retained as part of the 
model definition. 

In the preferred embodiment, the "toDepartmenr" rela- 
tionship 870 is displayed to the user as an attribute of the 
employee entity 802 as illustrated in FIG. 9 A, for example. 
Using the interactive approach of the preferred embodiment, 
for example, the "toDepartmenr" attribute of the employee 
entity display 992 is selected (e.g., using a pointer device 
such as a mouse) to invoke a department entity display 994 
of the department entity 862. The attributes of the depart- 
ment entity 962 to be flattened into the employee entity 902 
are then selected from the department entity display 994. 
The "Description" attribute of the department entity display 
994 is selected to be included in the employee entity 802. 
FIG. 9B illustrates an update of the model definition of FIG. 
8 that includes the flattened attribute in employee entity 902, 
"toDepartmentDescription". 

The attribute name "toDepartment.Description" is used 
herein to illustrate the traversal path and the attribute 
selected from the destination entity and included in the 
source entity. The traversal path and the selected attribute 
define the flattened attribute. This definition (e.g., 
"toDepartmenLDescription") is maintained in the model 
definition. However, a different reference name, such as 
"Description", can be used to refer to the flattened attribute 
external to the model definition. Therefore, for example, an 
object class can use the reference name "Description" to 
identify the "toDepartment.Description" flattened attribute 
of the employee entity 902. 

As previously described, the employee entity 802 is 
mapped to the employee table 402 and the department entity 
is mapped to the department table 462. By flattening the 
"Description" attribute of the department entity into the 
employee entity 902, the employee entity maps to two 
DBMS tables, the employee tabic 402 and the department 
table 462. By flattening the "Description" attribute of the 
department entity 862 into toe employee entity 902, the 
employee object 524 extends across (maps to) both the 
employee table 402 and the department table 462. The object 
class associated with employee entity 902, employee object 
524, is therefore mapped to multiple tables. 

Referring to FIG. 8, other examples of relationships are 
illustrated. For example, a "toAddress" relationship 876 
between the employee entity 802 and address entity 822 is 
defined using the "Address Id." attribute of each entity to 
establish a traversal path. Using the employee entity 802 as 
the source entity, the attributes of the address entity 822 can 
be flattened into the employee entity. Thus, some or all of the 
employee's address becomes part of the attributes of the 
employee entity 802. 

Similarly, a "toProject" relationship 878 is defined 
between the employee entity 802 and the project entity 842 
using the "Employee Id." attributes. A "toBuilding" rela- 
tionship 872 is defined between the department entity 862 
and the building entity 882 using the "Building Id." 
attributes of the two entities. Using the "Address Id." 
attributes of the building entity 882 and the address entity 
822, a "toAddress" relationship 874 is established between 
the two entities. 

In the above examples, a simple key is used as a rela- 
tionship key. A simple key is comprised of a single attribute. 
However, a compound key can be used as a relationship key. 
A compound key is a key that combines at least two 
attributes. In this case, the group of attributes that comprise 
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the compound, taken in combination, can uniquely identify Using the employeeProject entity 1292 as an auxiliary 

an instance of the destination entity. entity, a "many-to-many" relationship is created between the 

Relationships arc unidirectional. That is, the path that employee entity 1202 and project entity 1242. Thus, each 
leads from the source entity to the destination entity is not employee can be assigned to zero, one, or many projects, 
traveled in the opposite direction. Unidirectionality is 5 Similarly, each project can have zero, one, or many employ- 
enforced by the way in which a relationship is resolved. As ccs wor kin g on the project. Further, the employeeProject 
described above, the resolution of a relationship is accom- 1292 creates a bi-directional relationship between the 
plished by finding the correct destination record(s) for a employee entity 1202 and project entity 1242. 
giveD source record. In the examples provided above, the source and destina- 

Umdirecuonal relationships can be used to create a j() ^ &n fa ^ mQdel However> it 

bi-directional relationship. Two traversal paths exist k fof and destioation emilies l0 be the 

between two entities (a source entity and a destination r . . ~. . # . , . 4 . _ , 

entity) having a bi-directional relationship. One path sameentity. ™° ^mtop ^ated usmg the same entity 

traverses from the source entity to the destination entity. A » ^ ma f c . and destination entity is referred to as a 

second path traverses from the destination entity to the reflexive relationship. Reflexive relationships provide the 

source entity. For example, a model includes relationships 15 abi % for 311 ™stoxc of an cntlt y to P omt to another 

"A" and "B**. Relationship "A" is the inverse of relationship instance of the same entity. Reflexive relationships can 

"B". Effectively, relationship "A" has as its source entity and represent an arbitrarily deep recursion, 

its source attributes, the destination entity and destination FIG. 13 illustrates a reflexive relationship. Instead of 

attributes of relationship "B". Relationship "B" has as its creating a separate manager entity, the employee entity 1302 

source entity and its source attributes, the destination entity 20 can be used for a manager instance and for an employee 

and destination attributes of relationship "A". instance that reports to a manager instance. Reflexive rela- 

A bi-directional relationship may be created using any tionship 1390 is formed using the employee entity 1302 as 

technique for establishing a dual relationship between enti- the source and destination entity. The "Manager Id." 

ties. For example, a bi-directional relationship between two attribute of the employee entity 1302 is the relationship's 

entities is created using an auxiliary entity. The creation of 25 source key. The "Employee Id." attribute of the employee 

an auxiliary entity between the two entities creates a net- entity 1302 is the relationship's destination key. 

work of relationships between the two entities via the Reflexive relationship 1390, or "managcrOf* relationship, 

auxiliary entity. FIG. 12 illustrates a bi-directional relation- can be recursive. For example, a first employee can report to 

ship using an auxiliary entity. a second employee who reports to a third employee. This 

The employee entity 1202 and project entity 1242 are the 30 relationship can continue until an employee has a null 

same as the employee entity 802 and project entity 842 "Manager Id." indicating that employee does not report to 

described above. EmployeeProject entity 1292 is the auxil- another employee. 

iary entity that creates the relationship network between A flattened attribute can extend across multiple relation- 
employee entity 1202 and project entity 1242. The employ- ships. Any number of relationships can be traversed to 
eeProject entity 1292 uses a compound key consisting of 35 flatten attributes. Referring to FIG. 8, for example, relation- 
"Employee Id." and "Project Id .". The table associated with ships 870, 872, and 874 can be combined to include an 
the employeeProject 1292 holds a different record for each employee's business address in the employee entity 802. 
employee of every project. The compound key uniquely Using relationship 870, a relationship is created between the 
identifies each record in the table associated with the employee entity 802 and the department entity 862. Using 
employeeProject entity 1292. 40 relationship 872, the building entity 882 and department 
The relationships between the entities are created as entity 862 are related By combining relationships 870 and 
described above. Employee entity 1202 has two relation- 872, it is possible to include the building location for an 
ships 1290 and 1292 with employeeProject entity 1292. In employee into toe employee entity 802. Using the relation- 
relationship 1290, employeeProject entity 1292 is the source ship between the building entity 882 and address entity 822, 
entity and employee entity 1202 is the destination entity. The 45 it is possible to include the address of the building in which 
"Employee Id." attributes of the employee entity 1202 and an employee is located (i.e., the employee's business 
employeeProject entity 1292 are the relationship keys. The address) into the employee entity 802. 
traversal path of relationship 1290 is illustrated by the arrow Flattened Relationship 

pointing toward employee entity 1202 from employ- In addition to flattening attributes, the present invention 
eeProject 1292. The single arrow indicates a "to-one" rela- 50 provides the ability to flatten relationships. Flattening a 
tionship. In a "to-one" relationship, there is exactly one relationship gives a source entity access to relationships that 
destination record for each source record. Thus, for each a destination entity has with other entities. Referring to FIG. 
employee Project instance, there is exactly one employee 8, employee entity 802 is related as the source entity to 
instance. A second relationship exists from the employee department entity 862 (the destination entity) via relation- 
entity 1202 (the source entity) to the employeeProject entity 55 ship 870. The destination entity of relationship 870 
1292 (the destination entity). As illustrated by the double (department entity 862) is related to building entity 882 via 
arrows of relationship 1292, for each employee instance relationship 872. Thus, the employee entity 802 is related to 
there are zero, one, or many employeeProject instances. the building entity 882 via the department entity 862. 
Thus, each employee can be assigned none to many projects. Relationships 870 and 872 can be flattened such that 
Similarly, there are two relationships (1294 and 1296) 60 employee entity 802 is effectively related to building entity 
between employeeProject entity 1292 and project entity 882 via a single relationship. 

1242. Relationship 1294 creates a "to-one" relationship FIG. 11 illustrates a FhttenRelationship process flow. At 

between the employeeProject entity 1292 and project entity block 1102, a relationship is created between a first and 

1242 using the "Project Id." as the relationship key. Rela- second entity as described above with reference to flattening 

tionship 1296 is a "to-many" relationship. Thus, for each 55 attributes. At block 1104, a relationship is created between 

project instance, there are zero, one, or many employ- the second entity and a third entity. At block 1106, a 

eeProject instances. relationship of the second entity (e.g., the relationship 
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between the second and third entities) is selected to be SQL select statement, for example, is generated to select the 

flattened. The FlattenRelationship process flow can be columns from the tables to which the fetched objects are 

repeated to flatten additional relationships. mapped. For example, the model is used to generate a select 

FIGS. 14A-14C illustrate the FlattenRelationship process statement to fetch an employee object. The select statement 

from a user's viewpoint by selecting relationships provided 5 selects a record from the employee table 402 comprising the 

in displays presented to the user in an interactive environ- columns 

ment. FIG. 14 includes a graphical representations 1402, Referring to FIG. 5, the employee object 524 includes a 
1422, 1462, and 1482 of the employee entity 802, address "Description" property that maps to the "Description" flat- 
entity 822, department entity 862, and building entity 882, tened attribute of the employee entity 902. When an 
respectively. Using the FlattenRelationship process, the user 10 employee object 524 is fetched from the DBMS, a join is 
specifies a flattened relationship between the employee performed using a select statement to populate an instance of 
entity 802 and the address entity 822. the employee object 524. The "where clause" of the select 

Referring to FIG. 14A, employee entity 1402, department statement contains a phrase that requires the relationship 

entity 1462, and building entity 1482 have relationship keys ("Department Id.") of the employee table 402 and 

attributes "toDepartment", "toBuilding", and "toAddress", 15 department table 462 to be equal. That is, when an employee 

respectively. The FlattenRelationship process is used repeat- object 524 is fetched at runtime, the "Department Id." value 

edly to create a flattened relationship between employee of the employee object 524 is compared to the values of the 

entity 1402 and address entity 1422. "Department Id." column of the department table 462 to 

The "toBuilding" relationship of department entity 1462 locate the desired department record. Once the desired 

is selected and the flatten relationship operation is selected. 20 department record is located, the properties of the employee 

Referring to FIG. 14B, the result of this process is the object 524 that correspond to the flattened attributes of the 

inclusion of a "tobuilding" relationship attribute in the employee model entity 802 from the department model 

employee entity 1402. A similar process is used to create a entity 862 can be loaded into employee object 524. 

"to Address flattened relationship in employee entity 1402. Fetching all of the objects at one time requires a signifi- 

As illustrated in FIG. 14B, the "toAddress" relationship is 25 cant allocation of memory to retain all of the objects until 

selected from the building entity 1482, and the flatten they are processed. Instead of fetching all of the objects at 

relationship operation is selected. Referring to FIG. 14C, the one time, the objects can be fetched as they are needed using 

result of this process is the inclusion of the "toAddress" a fetch loop. FIG. 15 provides a fetchLoop process flow. At 

flattened attribute in the employee entity 1402. block 1502, the model entity associated with the object to be 

Fetch and Update 30 fetched is examined to determine the table(s) and column(s) 

At runtime, objects are fetched and populated with data associated with the object to be fetched. Using the model 

from a data source (e.g., DBMS). The model is used to map entity definition, a select statement is generated to select the 

the data to the fetched objects. The model maps columns of DBMS records needed to populate the objects. A fetch order 

the database to properties of the object. Therefore, the model of the records can also be specified at block 1506. A 

can be used to bind a column's data values to a property (i.e., 35 transaction is initiated at block 1508. 

instance variable) of the object. A key- value communication The records are selected using the select statement at 

protocol is used, for example, that identifies a key (e.g., block 1510. At block 1512, an object is fetched using a 

column name) and a data value associated with the key. The selected record to populate the object At block 1514, the 

key is used to identify the instance variable. Once the object is processed. The methods of the object manipulate 

instance variable is identified, the value associated with the 40 the data of the object during processing, for example. Once 

key is used to initialize the instance variable. The key-value object processing is completed, processing continues at 

coding communication protocol is more fully described in a decision block 1516. At decision block 1516 (i.e., "all 

co-pending U.S. Patent Application entitled "Dynamic objects processed?"), if all of the objects have not been 

Object Communication Protocol", Ser. No. 08/353,524, filed processed, processing continues at block 1512 to fetch 

on Dec 7, 1994 and incorporated herein by reference and is 45 another object. 

abandoned. If it is determined, at decision block 1516, that all of the 

Objects are fetched all at one time, for example. Objects objects are processed, processing continues at block 1518. 

can also be fetched using a fetch loop. As objects are The model is used to map any changes made by an object to 

fetched, model relationships between the objects must be the DBMS. For example, an object's associated model entity 

resolved. Relationships between objects are resolved, for so is examined to identify the DBMS table(s) and column(s) 

example, by creating a "fault" object that stands in for an modified by the object. The modifications are then propa- 

actual object. A "fault" object contains a pointer to the data gated to the DBMS using the mapping provided by the 

that can be used to initialize an actual object that is instan- model The model is used to determine the tables that are 

tiated to replace the "fault" object. An actual object is affected by the modifications made by the object. SQL 

instantiated to replace the "fault" object when a message is 55 statements are generated to update the tables. Where an 

sent to me "fault" object to which it can not respond. A more object is mapped to multiple tables of the database, for 

complete description of stand-in objects is provided in a example, multiple SQL statements can be generated to 

co-pending U.S. Patent Application entitled "Method for update each table. At block 1518, the changes made to the 

Providing Stand-in Objects", Ser. No. 08/353,523, filed on DBMS by the object are either committed or rolled back. At 

Dec. 7, 1994 and incorporated herein by reference and is 60 block 1520, fetchLoop processing ends, 

abandoned. Thus, a method and apparatus for method and apparatus 

Whether or not objects are fetched one at a time or using for mapping objects to multiple tables of a database has been 

a fetch loop, to fetch an object and populate the object with provided, 

data from a DBMS, for example, the model is used to What is claimed is: 

determine the association between the object and the DBMS 65 1. A method of mapping object transparently to a data 

table(s) and the association between object properties and source stored in a storage medium in a computer system 

columns of the DBMS tables. Using these associations, an comprising the steps of: 
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independently defining an object class; using said first entity's definition to propagate said modi- 

independently defining a schema for said data source, said ficatioD made b Y said ob i M t0 firsl and 560011(1 

schema defining being independent of said object class tables. 

defining; and An article of manufacture comprising: 

defining a model providing a mapping between properties 5 a computer usable medium having computer readable 

of said object class and data of said data source schema, program code embodied therein for mapping an object 

such that the mapping between said data source schema transparently to a data source comprising: 

and said object class is transparent to said object class computer readable program code configured to cause a 

and said data source schema. computer to independently define an object class; 

2. The method of claim 1 where in said data source schema 10 computer readable program code configured to cause a 
is a database schema. computer to independently define a schema for said 

3. The method of claim 2 wherein said model is comprised data source, said schema defining being independent of 
of at least one entity that has at least one attribute. said object class defining; and 

4. The method of claim 3 wherein said attribute is a simple 1S computer readable program code configured to cause a 
attribute that maps directly to an item of data in said data computer to create a mapping between said object class 

and said data source schema using a mapping model, 

SOUr °!L ^» , • -i i said mapping between said data source schema and said 

5. The method of claim 3 wherein said attribute is a ^ eQt tQ ^ class and ^ 

derived attribute that does not directly map to an item of data data schema. 

in said data source. 20 12. The article of manufacture of claim 11 wherein said 

6. The method of claim 3 wherein said model has a object class includes a property, said program code config- 
plurality of entities and a plurality of relationships between urec j t0 a comp uter to create further comprising: 

at least two of said plurality of entities. computer readable program code configured to cause a 

7. The method of claim 1 further comprising the steps of: 25 computer to create and entity in said mapping model; 
defining a first entity of said model having a first attribute; computer readable program code configured to cause a 
defining a second entity of said model; computer to relate said entity to said schema; 
defining a relationship between said first and second computer readable program code configured to cause a 

entities; and computer to create in said model an attribute for said 

using said relationship to define said first attribute as an 30 entity; and 

attribute of said second entity. computer readable program code configured to cause a 

8. The method of claim 1 further comprising the steps of: computer to relate said entity to said property, 
defining a first entity of said model; 13 ™ e of manufacture of claim 12 wherein said 

defining a second entity of said model; 35 daU ^ * 3 'T^f ***** * ^ T* 

. , n . j i program code configured to cause a computer to relate 

defining a first relationship between said first and second ; , . . 

entities; fsuibsr uprising: 

defining a third entity of said model; computer readable program code configured to cause a 

, „ . . _ , , computer to relate said entity to said table m said 

defining a second relationship between said second and . . 1 j * t_ 

° .. , 4Q relational database, 

tmrd entities; and 14 ^ of manufacturc of claim 12 wherein said 

defining a third relationship between said first and third daU source ^ a relational databasc havin a table> ^ 

entities using said first and second relationships. , „ , , „ , . . 

9. A method of mapping an object transparently to a table P ro S ram code c ™^f * cause a »mputer to relate said 
of a database stored in a storage medium in a computer < entitv to fiuther °° m P™ 

system comprising the steps of: computer readable program code configured to cause a 

. . computer to relate said attribute of said entity to a 

independently defining a property for an object class; column of said table in said relational database. 

independently defining a first table having one or more 15 -j^e article of manufacture of claim 11 wherein said 

attributes, said first table defining being independent of mappill g mod el includes a plurality of entities, each of said 

said property defining; 50 pluraJity of CQtilies having a plurality of attributes and a 

defining a model having an entity that corresponds with plmalily of relationships, wherein at least one of said 

said first table, relationships exists with at least one entity of said mapping 

defining in said entity a flattened attribute, said flattened mo^L 

attribute being an attribute of a second entity that _ . . _ <. fl . 1t , . . , 

corresponds rtth a second lablc; and « 16. Tlie artick of manufacmrc of claam U whereui said 

.... . , , mapping model includes a plurahty or entities, each ot said 

associating said object with said first entity thereby asso- . , . . i t*. c « u ♦ a 

dating laid object with said first table and said second of eDtmes hivm & » ptantey of attributes and a 

lafolz plurality of relationships, wherein at least one of said 

10. The method of claim 9 further comprising the steps of: plurahty of relationships is a reflexive relationship that 

generating, using said first entity's definition, a statement 60 cxists bctwccn *»° of P luraUtv of atlributcs m onc of 

to fetch a record from a database; said plurality of entities, 

instantiating an instance of said object class and loading 17 ^ article of manufacture of claim 11 wherein said 

said property of said instance with a data value con- mapping model includes a plurality of entities, each of said 

tained in said record; 65 plurality of entities having a plurality of attributes and a 

modifying said property using one or more methods of plurality of relationships, wherein at least one of said 

said object; and plurality of relationships is a flattened relationship that 
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relates two of said plurality of entities via one or more 
intermediate entities. 

18. The article of manufacture of claim 11 wherein said 
mapping model includes a plurality of entities, each of said 
plurality of entities having a plurality of attributes and a 5 
plurality of relationships, wherein one of said plurality of 
relationships relate s at least one of said plurality of objects 

to multiple schema entities of s aid data source. 

19. The article of manufacture of claim 18 wherein a l0 
schema entity is a database table. 

20. The article of manufacture of claim 18 further com- 
prising: 



computer readable program code configured to cause a 
computer to identify a first relationship key in a first of 
said plurality of entities; 

computer readable program code configured to cause a 
computer to identify a second relationship key in a 
second if said plurality of said entities; and 

computer readable program code configured to cause a 
computer to define a traversal path using said first and 
second relationship keys. 
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